OpsgenieのAliasを使ってJira Service Managementへの重複除外アラート連携をやってみた
こんにちは、たかやまです。
最近Jira Service Management(JSM)とOpsgenieを触っており、OpsgenieのAlias機能を使ってE-mail通知の重複除外とJira Service Managementへのインシデント起票を行ったので今回はその手順をご紹介します。
※JSMとOpsgenieは統合が進んでおり、UIや機能が変更されています。ここでは以前Opsgenieとして提供していた機能についてOpsgenieとして記載しています。
ちなみにJSMとOpsgenieとは
両サービスともAtlassian社が提供しているサービスです。
Jira Service Management(以下、JSM)は、Jira Service Deskの後継として、ITサービスマネジメントを支援するためのサービスです。Jira Service Deskの機能に加え、ITILのベストプラクティスに準拠した機能が追加されています。また、Jira SoftwareやConfluenceとの連携も可能で、組織全体のサービスマネジメントを効率化します。
Opsgenieは、システム障害やアラートが発生した際のインシデント管理を支援するサービスです。メール、SMS、電話などの様々な通知チャネルを通じて、アラートの配信やエスカレーションを自動化し、24時間365日のアラート管理を実現します。
また、Slack、Jiraなどの主要なツールとの連携に加え、AWSのCloudWatchやAmazon SNSとの連携により、アラート管理を効率的に行うことができます。
また、Alias機能はOpsgenieが提供するアラートの重複除外機能です。アラートの一意性を識別するためのキーとなる値をAliasとして設定することで、重複アラートを除外することができます。
やりたいことと全体構成
やりたいことは以下の通りです。
- OpsgenieのIntegrationとAlias機能を使って、E-mail通知の重複除外を行いつつアラート作成する
- 障害発生時にアラートを起票し、JSMにチケットを作成する
- 重複アラートの場合、新規チケットを作成せずにカウントアップする
- 障害解消時([OK])にアラートをクローズし、JSMのチケットステータスを自動更新する
- 障害発生時にアラートを起票し、JSMにチケットを作成する
- OpsgenieのSync機能を使って、JSMのチケット起票およびステータスの自動更新を行う
やってみた
Atlassianチームを作成する
Opsgenieを利用するにはAtlassianチームを作成する必要があります。
すでにAtlassianチームを作成されているかたは、次のステップのE-mailインテグレーションの設定から進めてください。
AtlassianチームはJSMの上部タブにある「チーム」 > 「チームを作成」から作成できます。
作成画面で任意の「チーム名」と「招待するユーザー」を選択してください。
作成されると、さきほどのタブから作成されたチームを確認できます。
チームの画面から「Operations」という項目があるので、こちらの Get started
をクリックしてOpsgenieの設定を進めていきます。
まだ「Operations」の機能を有効にしていない場合には、以下のような開始画面が表示されるので進めていきます。
以下のOperationsの画面が表示されたら、Opsgenie開始に向けての設定が完了です。
OpsgenieにE-mailインテグレーションを作成する
インテグレーションは、Opsgenieと他のモニタリングツールやサービスを接続し、アラートの一元管理と効率的なインシデント対応を実現する機能です。
今回はE-mailをOpsgenieで受信しアラートを作成するためのインテグレーションを作成します。
インテグレーションの作成はサイドメニューから「Integrations」 > 「Add integration」を選択してください。
インテグレーション一覧で「Email」を選択してください。
任意の「Integration name」を入力して「Continue」をクリックしてください。
インテグレーションが作成されると、Integration settingsが表示されます。
今回は以下のような件名の障害通知のメールを受信した際にアラートを起票及び重複除外しつつ、障害解消時はチケットをクローズする設定をするために「Create alert」と「Close alert」を設定していきます。
[PROBLEM] High CPU usage - WebServer01 <- 複数来る場合は重複除外する
[OK] High CPU usage - WebServer01 <- 障害解消時は対象のアラートをクローズする
まずは「Create alert」を設定します。Create alertはデフォルト作成されているので、「・・・」 > 「Edit」から編集します。
設定画面では追加で以下の設定を行います。
- Filter alerts
- Only alerts that match all the conditions
Subject
Not
Contains
OK
- Alias
{{subject.extract(/\[.*?\]\s+(.*?)$/)}}
「Filter alerts」はアラートの件名に「OK」が含まれていないものをアラートとして作成するための設定です。
「Alias」はアラートの重複除外のための設定です。Aliasはアラートの一意性を識別するためのキーとなります。今回はアラートの件名から「High CPU usage - WebServer01」の部分を抽出してAliasとして設定するための正規表現を記述しています。
正規表現の記述方法はこちらを参照してください。
次に「Close alert」を設定します。Close alertはデフォルトで作成されていないので、「+ Add rule」から追加します。
Close alertの設定画面では以下の設定を行います。
- Rule type
Close alert
- Filter alerts
- Only alerts that match all the conditions
Subject
--
Contains
OK
- Alias
{{subject.extract(/\[.*?\]\s+(.*?)$/)}}
ここでの「Filter alerts」はアラートの件名に「OK」が含まれているものをアラートとしてクローズするための設定です。
「Alias」は、Create alertと同様の値とすることで、Create alertで作成したアラートと紐づけることができます。
ここまでがE-mailインテグレーションの設定です。
OpsgenieにSyncを作成する
次にOpsgenieにSyncを作成します。
SyncはJSMとOpsgenieが統合されるなかでリリースされた機能で、従来のOpsgenieのJSMインテグレーションの機能に変わるものです。
OpsgenieとJSMの統合についてはこちらのページを参照してください。
Syncの作成はサイドメニューから「Sync」 > 「Create sync」を選択してください。
Syncの作成画面で以下の設定を行います。
- Choose your project's Jira site
Current Jira site
- Project
- チケットを起票したいJSMプロジェクト
Syncを作成すると、「Sync settings」の画面が表示されます。
こちらではいくつかのルールがすでにデフォルトとして設定されていますが、以下のルールは今回使用しないため「Turn off」します。
- Create alert
- Acknowledge alert
- Add note to alert
「Close alert」について、JSMのステータス変更でアラートをクローズしたいため以下の設定を行います。
- Filter alerts
- Only alerts that match all the conditions
Status Name
--
Equals
<アラートクローズ条件>
「Filter alerts」として、JSM側でチケットを特定のステータスにした場合(ここではインシデント回復
)にアラートをクローズするための設定をしています。
次に「OK」の件名を含むメールを受信した際に、インテグレーションからアラートをCloseされると同時にJSMのチケットのステータスを変更するための設定を行います。
折りたたみ & 非活性化されている場合には「Rules for taking actions against alerts」 > 「Create and update issues against alerts created by integrations or other syncs」 > 「+ Add rule」から追加します。
設定内容は以下の通りです。
- Filter alerts
- Only alerts that match all the conditions
Source
--
Equals
Email
- Update actions
- If
alert is closed
,transition issue status
<アラートクローズ時のJSMステータス>
in the issue
- If
「Filter alerts」の 設定をすることで、E-mailインテグレーションで作成されたアラートのみを対象にすることができます。
「Update actions」ではアラートがクローズされた際に、JSMのチケットのステータスを変更するための設定を行います。ここではアラートがクローズされた際にJSMのチケットのステータスをインシデント回復
に変更する設定をしています。
動作確認
ここまででE-mailインテグレーションとSyncの設定が完了しました。
では、実際にE-mailでアラートを作成し、JSMのチケットが作成されるか確認してみましょう。
送信先の宛先は、E-mailインテグレーションのEmail addressになります。
こちらに以下の内容のメールを送信します。
Emailインテグレーションが動作すると以下のようなアラートと、JSMのチケットが作成されます。
再度同様のサーバの通知がきた場合を想定して、同じメールを送信します。
(Event time部分を少し変えたりしてます)
アラート確認すると先程のアラートの数字がカウントアップされ「x2」になっていることが確認できます。
このとき、アラートのAliasは「High CPU usage - WebServer01」が設定されており、同じAliasのアラートが作成された場合には重複除外されるようになっています。
この状態で、JSMのチケットを確認すると、新規にチケットが起票されていないことが確認できます。
最後に、アラートをクローズするためにステータスが回復されたことを示す「OK」が含まれたメールを送信します。
アラートを確認すると、先程のアラートがクローズされていることが確認できます。
JSMのチケットについてもステータスが「インシデント回復」に変更されていることが確認できました!
最後に
今回はOpsgenieのAlias機能を使ってE-mail通知の重複除外とJSMへのインシデント起票を行いました。
Aliasを活用することで、重複アラートを効率的に管理し、運用負荷を軽減することができます。
また、今回の記事では詳しく触れませんでしたが、JSMの自動化機能も組み合わせることでより柔軟な運用が可能になります。
JSMとOpsgenieの統合は現在進行中のため、本記事の内容が将来的に更新される可能性がありますが、ここで紹介した基本的な考え方は応用いただけるかと思います。
この記事がどなたかのお役に立てれば幸いです。
以上、たかやま(@nyan_kotaroo)でした。